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Adding Acronyms to Simplify Conversations about 
DNS-Based Authentication of Named Entities (DANE) 


Abstract 
Experience has shown that people get confused when discussing the 
three numeric fields of the TLSA record. This document specifies 
descriptive acronyms for the three numeric fields in TLSA records. 
This document updates the format of the IANA registry created by RFC 
6698. 
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1. Introduction 


During discussions on how to add DNS-Based Authentication of Named 
Entities (DANE) [RFC6698] technology to new protocols and services, 
people were repeatedly confused as to what the numeric values stood 
for and even the order of the fields of a TLSA record (note that TLSA 
is not an acronym but a name). This document updates the IANA 
registry definition for the TLSA record to add a column containing an 
acronym for each specified field, in order to reduce confusion. This 
document does not change the DANE protocol in any way. 


It is expected that DANE parsers in applications and DNS software can 
adopt parsing the acronyms for each field. 


2. IANA Considerations 


This document applies to the "DNS-Based Authentication of Named 
Entities (DANE) Parameters" registry located at <http://www.iana.org/ 
assignments/dane-parameters>. IANA has added a column with an 
acronym to each of the sub-registries. 


[RFC6698] and this document are the referenced documents for the 
three sub-registries. 


As these acronyms are offered for human consumption, case does not 


matter; it is expected that software that parses TLSA records will 
handle upper-, mixed-, or lower-case characters as input. 
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2.1. TLSA Certificate Usages Registry 


April 2014 


The reference for this registry has been updated to include both 
[RFC6698] and this document. 


4+------- +--- 
| Value | Ac 
4+------- +--- 
0 PK 
1 PK 
| 2 | DA 
| 3 | DA 
| 4-254 | 
| 255 | Pr 
4+------- +--- 
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Unassigned 


Reserved for Private Use 


e 1: TLSA Certificate Usages 
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SubjectPublicKeyInfo 
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Reserved for Private Use 


Table 2: TLSA Selectors 
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2.3. TLSA Matching Types 


The reference for this registry has been updated to include both 
[RFC6698] and this document. 


+------- +----------- $-------------------------- +------------- + 
| Value | Acronym | Short Description | Reference 
+------—- +----------- +-------------------------- +------------- + 
0 Full No hash used [RFC6698] 
1 SHA2-256 256 bit hash by SHA2 [RFC6234] 
| 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6234] | 
| 3-254 | | Unassigned | 
| 255 | PrivMatch | Reserved for Private Use | [RFC6698] | 
+-----—- +----------- +---------------—------—---— +-------------— + 


Table 3: TLSA Matching Types 
3. Examples of Usage 
Two examples are described below. 
3.1. TLSA Records Using/Displaying the Acronyms 


_666._tcp.first.example. TLSA PKIX-TA CERT SHA2-512 {blob} 
_666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} 


3.2. Acronym Use in a Specification Example 


Protocol FOO only allows TLSA records using PKIX-EE and DANE-EE, with 
selector SPKI, and using SHA2-512. 


4. Security Considerations 


This document only changes registry fields and does not change the 
behavior of any protocol. The hope is to reduce confusion, which 
would lead to better specification and operations. 
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